Managing global groups

When the Active Directory Connector is installed, all Active Directory groups in the configured organizational unit (OU) become Project Portal global groups. The main advantage of using global groups is that they are predefined in Active Directory and you do not need to re-create them in Project Portal. Member user accounts are also more likely to be kept up to date by the Active Directory administrators.

Tip Create a separate OU for storing and quickly finding all Project Portal-specific groups. Another technique is to use a separate group property that can be used to filter Project Portal groups from the whole Active Directory tree.

You may add and remove the global groups from workspaces. When a global group is added to a workspace, all of the users in that group become members of the workspace. You can also use global groups to manage access rights, assign them to status transitions, and so on just like Project Portal (local) access groups.

There are two major differences between access groups and global groups:

• A global group adds its member users to the workspace
• Global groups cannot be inherited (they can be members of local groups)
• Global groups cannot be added directly to roles. Instead, add the global group to an access group and assign the access group to the role.

The Active Directory Connector retrieves Active Directory group information only from the OU that was selected when the Active Directory Connector was installed. For more information about configuring the OU from which to retrieve Active Directory information, see the BlueCielo Project Portal Administrator's Guide.

All user group management must be performed using the Active Directory management tools:

• User groups can be created anywhere in the configured OU tree.
• User group changes. Groups can be safely moved within the configured OU tree. Project Portal refers to them by globally unique IDs (GUIDs). A group's GUID never changes, even if the group is moved or other data is changed.

Notes

• User accounts that have been moved to a different OU in Active Directory are still usable in Project Portal until they have been removed from Active Directory.
• Group information that has been changed in Active Directory might take up to 15 minutes to appear in Project Portal.
• Project Portal-specific groups should not be deleted from Active Directory as this may leave unrelated data in Project Portal. Instead, remove all users from the groups and clear the groups.

Tip    Create a folder in Active Directory specifically for cleared groups.

You should consistently use either global groups or access groups as much as possible within a single workspace. Using a combination of both group types is likely to cause problems in managing the groups and user memberships. One exception to this rule is that the Privileged group is always an access group only. You cannot grant workspace privileged access via a global group. You must always use the Privileged access group to give privileged access to a workspace.

Tip    We recommend that you use global groups in workspaces for corporate access or long-term document storage and use access groups for limited access or short-term workspaces. If you use global groups only, plan for managing the global groups that will be required for small groups of users. You might want to create a separate OU in the Active Directory tree to contain these groups and consider giving the workspace administrators access in Active Directory to create and manage the groups in that tree.

Note    For easy identification, the @ symbol is appended to global group names in Project Portal to distinguish them from access group names.

Working with AD groups in Project Portal is described in the following topics.